Digital Rights Management (DRM) is a set of technologies that provide the basis to control the distribution and consumption of digital content such as a ringing tone, a screen saver, a Java game, an image or a piece of music. In order to enhance the acceptance of DRM, standardization of DRM technologies has become an important issue. The Open Mobile Alliance (OMA) for example has specified the OMA DRM 2.0 standard for the protection of multimedia data on mobile telephones and other devices.
According to the OMA DRM 2.0 standard, digital content is protected by encryption and by packaging into a special DRM format (the DRM Content Format, such as DCF or PDCF). A key to decrypt the digital content is transferred in a so-called rights object. The rights object is issued by a rights issuer that may also distribute the rights object to the DRM capable device. The rights object is protected by encryption with a device specific public key that is stored in a DRM certificate. In addition to its public key, each DRM capable device has a private key for decrypting the rights object individually encrypted for this device.
Before a rights issuer can distribute a rights object to a device, both the rights issuer and the device must register with each other. For this purpose a Rights Object Acquisition Protocol (ROAP) is specified in the OMA DRM 2.0 standard. ROAP includes several DRM security mechanisms performed between the rights issuer and a DRM capable device. One of those security mechanisms specified by ROAP is an interactive 4-pass registration protocol. The registration protocol is generally only executed at first contact between the device and the rights issuer, but may also be executed one or more times after the first contact (e.g., when there is a need to update the exchanged information). The registration protocol specified in the OMA DRM 2.0 standard includes negotiations of protocol parameters and protocol version, cryptographic algorithms, exchange of certificate preferences, an optional exchange of the certificates, and the like.
FIG. 1 visualizes the 4-pass registration protocol between a device 10 and a rights issuer server 12 according to the OMA DRM 2.0 approach. In a first step the device 10 sends a DeviceHello message to the rights issuer server 12 to initiate the registration. The DeviceHello message includes device information (such as a device ID and cryptographic algorithms supported by device) and device preferences. In response to receipt of the DeviceHello message, the rights issuer server 12 sends an RIHello message back to the device 10. The RIHello message expresses preferences of the rights issuer as well as decisions performed by the rights issuer based on the information supplied with the DeviceHello message. In a third step the device 10 sends a RegistrationRequest message to the rights issuer server 12. With this message, further information is supplied to rights issuer server 12 such as a request time (i.e., the current DRM time as measured by the device 10) and a certificate chain parameter. The registration protocol ends with a RegistrationResponse message that is sent from the rights issuer server 12 to the device 10. The RegistrationResponse message includes status information, the Universal Resource Locater (URL) of the rights issuer server 12 and further information such as Online Certificate Status Protocol (OCSP) information. The OCSP information is obtained from the rights issuer server 12 during a 2-pass handshake procedure (steps a and b in FIG. 1) with an OCSP responder server 14 in the service network. The OCSP handshake procedure is executed to check whether the certificate provided by the device 10 to the rights issuer server 12 is still valid (the OCSP responder server keeps a list of revoked certificates).
In the OMA DRM 2.0 standard, the registration protocol is performed in context with generating a rights issuer context that enables the device 10 to successfully participate in further protocols of the ROAP suite, including protocols for requesting and acquiring rights objects that include information necessary to decrypt encrypted digital content. Only after the 4-pass registration protocol of FIG. 1 has been successfully concluded, the rights issuer server 12 can protect rights objects for the device 10. Successful completion of the registration protocol thus provides the device 10 with registration information negotiated with the rights issuer server 12 and required to use (e.g., play, hear or watch) protected content (that may have been received from a network component different from the rights issuer server 12).
Although the registration protocol described with reference to FIG. 1 reliably allows to establish a rights issuer context in the device 10, several drawbacks of this registration approach have become apparent. For example, while the digital content can be distributed over downlink-only channels to the device 10, the registration procedure shown in FIG. 1 always requires an interactive communication (and thus an uplink channel) from the device 10 to the rights issuer server 12. For this reason the registration protocol of FIG. 1 cannot be utilized in combination with systems only having a downlink channel (e.g., a broadcast system like Digital Video Broadcast, or DVB).
In Pekka Lahtinen, Maarten Muijen, “IPDC Services Purchase and Protection. Joint Response to the DVB CfT by Digita, Elisa, MTV Oy, NEC, Nokla, Phillips, Siemens, Swelcom, Telecom Italia Lab, TeliaSonera, T-System and Vodafone”, Version 1.0″ a 1-pass ROAP for registering an OMA DRM 2.0 compliant device with a rights issuer is proposed. According to this proposal the registration information is constructed by the device itself.
Accordingly, there is still a need for a registration technique that does not necessarily require an interactive communication in order to provide the device with registration information required to utilize protected content and that does not burden the device with excessive DRM processing operations.